Trade data has three dimensions, namely, transactional data (such as, for example, purchase order, invoice, etc.), master data (such as, for example, product information, location information etc.), and data about movement of physical goods across the supply chain (such as, for example, radio-frequency identification (RFID) electronic product code (EPC) event data). These data are available in different data services distributed over different trading partner networks. Master data may be available in industry standards based on a global data synchronization (GDS) network, product movement information is available in an EPC network and transaction data may be available in an electronic data interchange (EDI) and/or futuristic on-demand transactional information services network.
Typically, in existing approaches, an enterprise query (that is, a complex query that touches multiple enterprise applications) in supply chain applications involves complex cartesian joins across these three sets of data that are distributed in multiple data service end points. Added to the complexity is that the target service end points have to be determined dynamically. However, existing approaches do not include solutions that cater to all the three fields because, for example. RFID/EPG network is just starting to surface.
Additionally, existing approaches include many disadvantageous. For example, in some approaches, the client must issue a sequence of sub-queries directed at various services, and the physical markup language (PML) (that is, an XML-based language that defines data on objects) server does not have the ability to break the complex query to a set of sub-queries. Also, in some approaches, the PML server does not execute complex queries, and such approaches require the client to iteratively send sub-queries to multiple PML Services and the registry.
In other existing approaches, the PML service is not designed to produce a composite view. Some approaches may also, while processing a task, discover additional repositories, as well as construct new data acquisition tasks in addition to required data. Additionally, in some approaches, a crawling task, in addition to producing a result for insertion into the data space, produces new data acquisition tasks.
Other existing approaches cannot map an end user query to data source specific queries, while other approaches require storing acquired data to a database system before Query Processing Subsystem can process a user query. Further, some approaches consider only one type of data source (database), only EPCIS Simple Event queries, and only EPCIS related query decomposition.
In yet other disadvantageous existing approaches, all possible queries are not executed, as the user needs to select from predefined queries and/or conditions from an on-screen form.